Walk into most discrete manufacturing plants and you’ll still find the real production system of record living in a laminated binder or an Excel workbook with seventeen tabs and a macro nobody understands anymore. That’s the problem low-code platforms were built to kill, and to their credit, they’re good at killing it. Ignition’s Perspective module, Tulip’s app builder, HighByte’s data-modeling-plus-app layer, and the low-code app studios now bolted onto ERP suites all make the same pitch: give a process engineer or a shift supervisor a drag-and-drop canvas, connect it to a tag or a database table, and have a working andon board, changeover checklist, or SPC entry form running by the end of the day. No project charter, no six-month MES configuration cycle, no vendor services engagement.
That pitch is not hype. It’s real, and it’s why low-code is showing up as a standard line item in nearly every MES and unified namespace vendor’s renewal conversation this year. The problem is what happens next, which nobody puts on the slide: eighteen months later the plant has forty of these apps, built by twelve different people, half of whom have left or moved teams, none of them documented, and at least three of them quietly making decisions that affect quality holds or genealogy. You didn’t eliminate shadow IT. You gave it a nicer interface and a faster on-ramp.
The real distinction isn’t “low-code vs. MES.” It’s system of record vs. system of convenience.
Plant IT teams keep trying to draw the line based on the tool — “anything built in Tulip is fine, anything touching genealogy has to be in the MES.” That’s the wrong axis. The right question is what the app is being trusted to do. Is it a system of record that other decisions, audits, or regulatory submissions depend on? Or is it a system of convenience that makes a human’s job easier without becoming the authoritative source of anything?
A digital changeover checklist that replaces a paper form and logs completion time is a system of convenience, even if it’s genuinely valuable. A device that captures electronic batch records, enforces electronic signatures, and feeds a genealogy record used for regulatory release is a system of record, full stop — and it needs to live somewhere with formal validation, audit trails, and change control, whether that’s your core MES or a low-code platform configured and governed to that standard. Low-code tools can absolutely serve as systems of record in regulated environments; ISA-95 doesn’t care what IDE built the app. But that requires the same discipline — 21 CFR Part 11-style access control and e-signatures, versioned deployment, documented validation protocols — that you’d apply to a traditional MES module. Most plants skip that discipline precisely because the low-code pitch is “build it in an afternoon,” and validation discipline is the opposite of an afternoon.
A gate, not a form
The practical fix isn’t a 40-page policy nobody reads. It’s a short gate that every proposed app has to pass through before it gets built, and every plant I’d trust to do this well keeps it to a handful of questions:
- Does this app touch data that feeds a quality decision, a regulatory record, genealogy, or a safety interlock? If yes, it belongs under MES-grade governance regardless of what platform builds it.
- Does another system already do this? The number one failure mode isn’t malicious shadow IT — it’s a supervisor rebuilding a scheduling view that already exists in the MES because it’s faster to make a new one than to ask for a change to the old one. That’s a signal your core system’s change-request process is too slow, not that low-code is bad.
- Who owns this app after the builder moves on? Every app needs a named business owner, not just a named builder, before it goes live. If nobody can answer that, don’t approve it.
- Where does it live in source control? Ignition and Tulip both support versioned, exportable app definitions. If your citizen developers aren’t checking builds into a repository with rollback capability, you have no way to know what changed, when, or why the line went down after “just a small update.”
Tiering builders, not just apps
The other half of governance is deciding who’s allowed to build what, and this is where a lot of plants either lock everything down (killing the whole point of low-code) or leave it wide open (creating the sprawl). A tiered model works better than a binary one:
- Tier 1 — sandbox/convenience apps: operators and engineers can build and deploy without IT sign-off, but only against a read-only or clearly scoped data source, and only for non-record-keeping use cases — visual work instructions, informal dashboards, simple checklists.
- Tier 2 — connected operational apps: anything writing back to a PLC, historian, or database needs a controls engineer or MES admin review before go-live, plus a defined rollback plan.
- Tier 3 — systems of record: full validation lifecycle, IT/quality sign-off, formal version control, and a documented decommissioning plan before it’s built, not after.
That last part — decommissioning — is the piece almost everyone forgets. A one-off app has a natural lifespan tied to the product line, the shift pattern, or the person who built it. If there’s no plan for retiring it, it becomes exactly the artifact you were trying to eliminate: an undocumented workaround that outlives its usefulness and its owner, except now it’s live on the network instead of sitting in a drawer.
What this means for your 2026 planning
If low-code app-building is part of your MES or UNS renewal conversation this year — and it probably is — push the vendor past the demo. Ask specifically how their platform handles version control, rollback, role-based build permissions, and audit logging for citizen-built apps, not just for the core product. Ask what a validated deployment path looks like if one of these apps needs to become a system of record later. A vendor that’s thought seriously about governance will have concrete answers. One that only has the “build an app in an afternoon” story is selling you the fun part and leaving the plant to figure out the rest.
Low-code isn’t the enemy of good MES architecture — it’s a legitimate layer of it, sitting between rigid core configuration and the informal paper-and-spreadsheet layer it’s replacing. But a layer only works if someone’s actually managing it as a layer, with the same rigor you’d apply anywhere else data drives a decision. Otherwise you’ve just moved the shadow IT problem from Excel to a nicer canvas, and given it a faster way to multiply.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
